Cisco TrustSec入門　～実践・発展編｜注意すべき設計上のポイントとユースケース

　前回は、Cisco TrustSecの概要としてTrustSec導入による効果や動作の仕組み、必要なコンポーネント、「Classification」「Propagation」「Enforcement」の3つの主要フェーズについて説明した。連載第2回目となる本稿では、次の2つについて解説する。

 

　まず実践編では、TrustSecの実装で注意すべき設計上のポイントを実際の構築プロジェクトの経験をもとに説明。次に発展編では、TrustSecとほかのセキュリティソリューションの連携により、管理ネットワーク内での脅威検知から不正に通信する端末の隔離までをシームレスに実現するユースケースを紹介しよう。

 

　実践編では、次の3つを解説する。まず拡張性の観点から、（1）ISEでのSecurity Group Tag（SGT）付与ポリシールール数の上限、（2）Enforcer でのTernary Content Address able Memory（TCAM）の消費。可用性の観点から、（3）SXPのIP-SGTマッピング情報タイムアウトによる影響、の3点である。

 

 

　TrustSecによるアクセス制御のクライテリアとなるSGT付与ポリシーは、ISEに設定する。たとえば図表1のように、AD上に登録された所属グループを条件として、各ユーザーの認証時に条件が合致するユーザーグループに応じて、SGTを割り当てる（ユーザーグループは所属部署に相当）。

 

 

　ここで問題となるのが、ISEに設定可能なルール数の上限が600までに制限されていることである。AD上に定義されたユーザーグループそれぞれにSGTを付与する場合、SGT付与ポリシールールもユーザーグループと同じ数が必要になる。

 

　さらにユーザーグループは、将来的な組織改編による変更が予想される。重複期間を考慮すると、既存グループと新規グループの合計で上限の600をオーバーする可能性がある。　

 

　また実際はユーザーグループが異なる場合でも、通信ポリシーは複数のグループ間で同一のケースも多いと考えられるので、その場合は付与するSGTを可能な限り統一し、減らすことが推奨される。ISEの複合条件機能を用いて付与ルール数を削減することが、その対応策となる。

 

　ISEの複合条件機能では、図表2のようにAD上のユーザーグループ名をOR条件でキーワードマッチングするように設定できる。同一ポリシーのユーザーグループは複合条件で１つにまとめ、作成した複合条件をSGT付与ルールに用いることで付与ルール数を削減するのがポイントである。

 

 

 

 

　2つ目は、アクセス制御を実施するEnforcer Switchでのリソース消費についてである。

 

　CiscoスイッチはTCAMと呼ばれるメモリを用いて、ルーティングテーブルの検索、セキュリティ用ACL（Access Control List）、QoS用ACLなどの処理を高速化するアーキテクチャを備える。TCAMのリソースを使い切ると、CPU処理もしくは機能の処理自体がスキップされるので、TCAMのリソース消費が上限を超えないように設定することが重要である。

 

　なお、TCAM領域の上限値は製品モデルごとに異なる。TrustSecのセキュリティACLであるSGACL（Security Group Access Control List）も、製品モデルごとにTCAMのリソース上限が定められている。

 

　ここで注目すべきは、SGACLのTCAM消費ロジックと従来型ACLのTCAM消費ロジックが異なる点である。従来型ACLのTCAM消費ロジックは、単純に機器に設定したアクセス制御定義の行数と考える。たとえば図表3の場合は、合計で「4」の消費となる。

 

　一方、SGACLの場合は、ISEに定義した送信元SGTと宛先SGTによって構成されたマトリクスの各セルに適用したアクセス制御ルールの合計数となる。たとえば図表4のように、マトリクスのセルが25個あり、各セルに4行のアクセス制御定義を適用した場合、25 × 4 で合計「100」の消費となる。

 

 

　SGTの数の増加に伴い、自動的にマトリクスセルの総数が増えるため、Enforcer SwitchのTCAM上限を超過しないように考慮する必要がある。

 

　なお、各スイッチ型番におけるSGACLのTCAM上限については、Cisco社が公開しているTrustSec System Bulletin（＊1）で参照できる。通信要件と必要なSGTの数からTCAMリソースの消費概算を事前に算出し、Bulletinのデータから必要数を満足させるハードウェアを選定するよう強く推奨したい。

 

････････

 

 

　Enforcer SwitchがSGACLをISEからダウンロードする条件は、「Enforcer自身が学習済みのIP-SGTマッピング情報に基づくSGT番号を宛先とするSGACLが、ISE上に定義されていること」である。言い換えれば、Enforcerが特定の宛先SGTに対するSGACLをダウンロードするには、Enforcerが該当の宛先SGTを学習しておかねばならない。

 

　IP-SGTマッピング情報をEnforcerに学習させる手段には、前回解説したように、Inline TaggingとSXP（SGT Exchange Protocol over TCP）の2通りがある。　TrustSec導入プロジェクトでは、Inline Taggingをサポートしない機器が介在しても、SGTの学習が可能なSXPを採用し、ISEに設定したサーバーなどの静的IP-SGTマッピング情報や、クライアント認証時にISEが生成した動的IP-SGTマッピング情報をEnforcerに学習させるよう設計した（図表5）。

 

 

 

 

　ここでEnforcerがダウンロードしたIP-SGTマッピング情報は、正常状態であれば問題ない。しかしISEの障害や途中経路のネットワーク障害で、ISEとEnforcerが通信不能となった場合に問題が顕在化する。ISEとEnforcer間で通信不能になると、以下のような流れでSGACLが消失する。

 

①SXP コネクションタイムアウトにより、ISEとEnforcer間のSXPコネクション切断

 

②SXPコネクションが回復しない場合、SXPのエージングタイムアウトによりEnforcerがSXPコネクション切断前までに学習したIP-SGTマッピング情報が消失

 

③EnforcerからIP-SGTマッピング情報が消失したことにより、Enforcerでダウンロード済みであったSGACLが消失

 

　③の時点ではEnforcerからアクセス制御のルールが消失しているため、本来ブロックすべき通信を許可する状態になる。従来型ACLはISEとの通信可否に関わらず、機器に設定が保持されるのでこのような状況にはならない。しかしSGACLは、ISEから動的にSGACLをダウンロードする仕組みなので、障害時に前述のような事象が発生する。従って、EnforcerがIP-SGTマッピング情報を学習した状態を維持することが非常に重要となる。

 

　対策としては、機器やネットワーク経路の冗長化はもちろんだが、ISEの2重障害なども考慮して、EnforcerのSXPエージングタイムアウトを延ばす手段が有効である。　　SXPのエージングタイムアウトは、正式には「SXP Reconciliation Period」という名称のタイマーであり、このタイマーの期限内であれば、SXPコネクション切断前までに学習したIP-SGTマッピング情報を保持できる。

 

　Reconciliation Periodは設定変更できるので、デフォルトの120秒から延長して数時間にすることで、障害発生後もEnforcerにおけるIP-SGTマッピング情報の維持、さらにSGACLの維持も可能となる。

 

 

 

　続いて、TrustSecと他のソリューションを組み合わせた発展編である。

 

　この組み合わせの連携は、Cisco社が提唱するNetwork as a Sensor（NaaS）とNetwork as an Enforcer（NaaE）という2つのセキュリティモデルにより構成されている。これらのモデルは、セキュリティ上の課題に対する1つの回答として生み出された。

 

　現状のセキュリティ対策として一般的なのは、「インターネットの入り口・出口にファイアウォール、IPS／IDSなどを設置した境界防御」である。しかし近年では内部犯行による情報漏洩や、マルウェア・ランサムウェアによる巧妙な標的型攻撃などが増加傾向にあり、境界防御のみでは防ぎきれない。そこで「企業ネットワーク侵入前にすべてを防ぐ」という考え方ではなく、「侵入されることを前提とした対策」が新たに必要となる。

 

　Cisco社では、企業ネットワーク内部侵入後の脅威に対応するため、「ネットワーク内部での脅威の動きの見える化」を実装することで、侵入した脅威を判断し、該当フローや感染端末を遮断するモデルを発表した。

 

　それがNaaSやNaaEである。NaaSやNaaEは、脅威検出のみ、もしくはネットワーク機器でのフロー遮断のみをそれぞれ単独で実施する場合に比べ、セキュリティ脅威の認識、感染端末の特定から最後の端末遮断までに要する時間が短く済むので、脅威による被害影響を最小化できる。

 

 

　NaaSのコンセプトは、NetFlowと呼ばれるネットワークトラフィックの可視化機能を企業ネットワーク内のスイッチやルータで有効化し、それらのスイッチやルータをあたかもセンサデバイスのように用いてネットワーク全体をセンサ化することである。

 

　NetFlowはCisco社が開発した機能であり、ネットワークの可視化に向けて広く利用されている。Cisco以外のベンダー機器でも多くサポートされており、センサデバイスはCisco機器以外でも構成できる。

 

　NetFlowでは図表6のように、NetFlowを有効化した機器で受信したパケットを検査し（①）、パケットの属性情報からフローテーブルを作成し（②）、フローテーブルをNetFlowパケットとしてモニタリング機器に送信し（③）、最終的にNetFlow送信先のモニタリング機器で解析してネットワークを可視化する。

 

 

　収集したNetFlowのデータからどのような情報を解析できるかは、NetFlowモニタリング機器の機能次第である。NaaSでは「Cisco Stealthwatch」という製品により、NetFlowのデータからトラフィックの流量や使用アプリケーションだけでなく、セキュリティ脅威も検出できる。

 

　Stealthwatch に実装されているパラメータ閾値やアノーマリ分析のアルゴリズムから、セキュリティ脅威検出の結果を一覧化し、さらに個別のアラームに対しても詳細に分析する。

 

 

　NaaSがネットワークの可視化から脅威の検出までの範囲をカバーするのに対し、NaaE は、Stealthwatchによって脅威であると検出されたフロー情報をシームレスに遮断する機能や、感染端末の隔離機能をサポートする。この2つの連携により、TrustSecが構成されている。

 

　Stealthwatchが検知した脅威情報を、TrustSecのポリシーコントローラーであるISEに伝達し、ユーザーIDなどのコンテキスト情報と結びつけるために、「Platform Exchange Grid」（以下、pxGrid（＊2））と呼ばれる機能をStealthwatchとISE間で使用する。pxGridはIETF標準に則ったAPIによるエコシステム機能で、Quarantine（検疫）というStealthwatchの脅威ステータスを、ISEで認証済みとなったクライアント端末に反映する。

 

････････

（＊2）「Cisco pxGrid At-a-Glance」http://bit.ly/2m2Us91

････････

 

　これにより、Stealthwatchで検出された感染端末をQuarantineに登録すると、認証時に、該当ユーザーへ当初割り当てたSGTを変更し、検疫用SGTに付け替える。さらにQuarantine後のSGTに紐づくSGACLのポリシーですべてのトラフィックをブロックするようなルールを定義しておけば、感染端末を隔離できる。

 

　図表7のように、トラフィックのフロー情報解析に始まり、感染端末の特定、感染端末の隔離までをシームレスに実施する。感染端末の調査やネットワーク機器での隔離設定追加作業を単独で実施する場合に比べると、大幅に時間を短縮できる。

 

＊

 

　以上本稿では、実践編で設計の重要ポイント、発展編でNaaS／NaaEモデルによるセキュリティ対策について説明した。

 

　実践編でも触れたが、TrustSec環境で使用する製品モデルによってサポート機能やキャパシティ情報が異なるので、最新のSystem Bulletin を参照することが導入成功の前提となる。またNetFlowやStealthwatchといったNaaSの仕組みとTrustSecを組み合わせることで、企業ネットワーク内にどのような脅威が潜んでいるかを解析し、マルウェア感染端末や内部犯行者の特定から被疑端末の隔離までをシームレスかつ短時間で実現できるようになる。

 

　このようにTrustSecは、ユーザーや端末状況の動的な変化に応じてセキュリティ・ポリシーを追随させ、IPアドレスやVLANなどネットワークの地理的条件に依存しない通信セグメンテーションを実行する主要技術になりえる。ぜひ今後も、TrustSecの動向に注目してほしい。

 

････････

････････

 

 

2009年、日本IBMシステムズ・エンジニアリング入社。入社以来、ネットワーク製品を中心とした技術支援に従事し、主に金融業界のネットワークプロジェクトに参画。ネットワークの設計や構築に携わる。現在はキャンパス・ネットワークやネットワーク・セキュリティに関する技術支援活動を行っている。